Generally, computerized hospital cart functions are controlled by an embedded microcontroller embedded within the cart. This type of architecture presents a variety of constraints and problems. In particular, the user interface (UI) for manually configuring and adjusting cart function parameters on the cart itself, such as lift speed, personal identification number (PIN) codes or other user access, identification and authentication, cart name or designation, timeouts, caster locks, drawer locks, drawer accessibility, etc., must be installed on the end-user's computer, where the end-user may be a healthcare provider or other healthcare entity that utilizes the hospital cart, such as a hospital, system of hospitals, hospital floor, hospital ward, doctor's office, homecare provider, long term care provider, ambulatory surgery centers, clinics, school health facilities, penitentiary health facilities, etc. The end-user's computer may be provided as a laptop, thin client, zero client. The end-user's computer, however, while having functionality with the cart and its microcontroller, is generally provided as a system remote from the cart and the embedded microcontroller. In some cases an end-user's computer is not utilized with the hospital cart at all.
Further, additional drivers must be installed on the end-user's computer in order for the UI to connect to the cart microcontroller via a dedicated connection, such as Universal Serial Bus (USB). Generally, the UI applications and USB drivers are only compatible with computers running a full version of the Microsoft Windows™ operating system.
Where multiple of hospital carts are concerned, fleet management applications are utilized. However, the connection to the end-user's computer is the only means to facilitate the use of fleet management application for each cart, including user access (PIN codes) management and power system management. In addition, there are separate local and fleet management UI applications for user management and power system management. The fleet management applications must be installed on each end user's network servers, such as a hospital system's network servers, which may not be possible depending on particular configuration of the servers and network security policies.
Once a hospital cart has been configured/set up and fielded (e.g., put into use), feature upgrades, or new functions potentially require a complete replacement of the old microcontroller circuit board with a new microcontroller circuit board. To make changes and updates, firmware and software changes have to be performed on a cart-by-cart basis, or require reinstallation of software on hospital servers.
These constraints cause a significant amount of cost and inconvenience to the hospital's Information Technology (IT) staff and other end user personnel, as well as manufacturer service departments, during setup, deployment, and maintenance of the hospital carts.
Existing solutions only attempt to solve some of these problems, but not all, and they require installation of software on the end user's computers and/or servers. These installations often conflict with the end user's other software, computers or network configurations, thereby making them unwieldy or infeasible to implement or maintain in many cases. Other solutions require multiple, inflexible hardware buttons to be installed on the hospital carts to control cart operations, limiting the ability to adjust to changing user needs.
End-users are also tasked with the responsibility of reacting and responding after problems arose instead of proactively, due to lack data visibility and staffing to manage fleets of carts. Further, it is common for end-users to follow less than optimal security practices in managing PIN codes and user access to the cart and/or drawers. Still further, end users often choose to keep cart parameters and settings static and constant, rather than changing them to adapt to changing user, workflow requirements and ergonomics. Lastly, end-users infrequently engage in implementing integrated solutions with their fleet of carts, due to greater planning and resources than many end users can afford.
Thus, there is a need to provide end users with a hospital cart that is more flexible in terms of its configuration, operation and maintenance, while keeping data files on the end-user's computer, such as confidential patient medical data, inaccessible from the hospital cart, and keeping the hospital cart autonomous with respect to the end-user's computer, such that there is no functional interdependence or data-sharing between the hospital cart and the end-user's computer.